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ABSTRACT 

EURECA, the EUropean REtrievable CArrier 
was launched on July 31st 1992. It is the 
largest ESA spacecraft ever launched, and the 
first one to be launched and retrieved by the 
NASA Space Shuttle. 

The many new aspects of this mission affected 
the operations concept and the ground 
segment design in all important areas: an off- 
line concept for mission control has been 
applied, based on automatic commanding 
and post-contact telemetry analysis; mission 
planning is the centre of all routine 
operations activities using dedicated tools and 
operational techniques; high precision orbit 
determination and daily update of related 
telecommands for spacecraft control are 
needed to cope with the requirements coming 
from the low altitude orbit and the spacecraft 
attitude control design. 

The papier describes the lessons learned 
during the first months of utilisation of the 
EURECA ground segment from the point of 
view of the flight control team. 
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1. INTRODUCTION 

EURECA, the first European spacecraft 
designed to be retrieved and re-used for 
subsequent flights, was launched on July 31st 
1992 on the NASA Space Shuttle Atlantis. 
After deployment it was manoeuvred to an 
operational circular orbit at 508 Km altitude, 
where it will carry out scientific operations for 
its fifteen payload instruments, mainly in the 
field of microgravity research and space 
science. After a planned mission of nine 
months the spacecraft will be transferred to a 
retrieval orbit, where it will rendez-vous with 
a new Space Shuttle, which will retrieve it 
and bring it back to Earth. 

The EURECA ground segment was designed 
around the mam mission characteristics of 
reduced visibility time and high level of 
spacecraft autonomy, large number of 
different possible payload operational 
configurations and packet telemetry and 
telecommand concepts. It consists or two 
ground stations in Maspalomas and Kourou, 
which provide about eight contact periods of 
5 to 10 minutes each every day, spaced by 
one orbit which lasts about 90 minutes (a long 
non-coverage period of about 9 hours occurs 


daily between two sequences of station 

E asses); and a control centre located in 
larmstadt, which can also make use of a 
third station in Perth as a back-up. 

For the periods when EURECA was attached 
or in proximity of the Space Shuttle contact 
with the spacecraft was established via the 
NASCOM network, the NASA TDRS system 
and the Orbiter itself used as a data relay 
station. In those periods, which include the 
first two days and the last few days of the 
mission, the contact with the spacecraft is 
practically continuous, and a completely 
separate telemetry and telecommand 
interface, as well as a different way of 
operation had to be defined. 

This paper does not describe the EURECA 
ground segment and control system, but 
rather the direct operational experience 
accumulated with the different parts of it and 
makes suggestions for possible future 
improvements. 

2. MISSION CONTROL SOFTWARE 
2.1 Database Editors 

The EURECA operational database was built 
manually using the manufacturer's spacecraft 
database developed for the system level 
testing activities, complemented by 
information collected in a large number of 
design documents. More than 8000 telemetry 
parameters, 2500 telecommands and 4800 
report messages had to be defined, an 
enormous task in terms of time and 
manpower both for creation and later 
maintenance of the files. 

The editors used for this task within the 
EURECA Dedicated Control System (EDCS) 
were also constraining this work, not 
providing the necessary level of flexibility, in 
particular when large changes to the source 
database had to be introduced. The solution 
of automatically importing into the 
operational database the industry developed 
spacecraft database would have helped in the 
traditional areas like housekeeping telemetry 
definition; the flexibility given by the 
EURECA packetised telemetry and 
telecommand concept would have been 
however significantly constrained if the entire 
database definition had been left to the 
industry. 

A mixed solution of general database 
information imported directly and later 
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processed using editors which are more 
change- oriented rather than input-oriented 
would probably satisfy all the needs of such a 
complex database generation task. 

2.2 User Interfaces 

The user interface for most of the tasks 
provided by EDCS to the EURECA flight 
control team is provided on workstations with 
very limited graphic capabilities, low speed 
of interaction with the central computer, and 
in general reduced flexibility in the use of the 
three available displays. 

For a complex mission like EURECA the 
standard spacecraft monitoring and 
commanding tasks controlled via the 
workstations require more display space for 
command building and displaying of the 
different types of telemetry; in addition 
several tasks related to ground data 
management and interface with the ground 
stations have also to be carried out by the 
spacecraft controller using the workstation. 
This resulted in an increased need of display 
availability, which can hardly be satisfied by 
the arrangement provided by the 
workstations. The limited graphic capabilities 
impact in particular the offline data analysis 
carried out daily by the flight control 
engineers. 

The combination of workstation and user 
interface limitations also practically prevented 
the creation of a database of mimic displays, 
normally very effective in summarising 
information and thus allowing savings in 
space and time. 

Interactive generation of telemetry displays is 
provided for graphic and alphanumeric 
scrolling displays. This was extensively used 
during system and spacecraft tests, ana it is 
still found very useful for quick-look analysis 
of unexpected spacecraft behaviour during 
flight. This type of features should be 
extended to all types of telemetry displays, 
from alphanumenc to mimic; the system 
should also allow a direct consolidation of the 
changes performed interactively at the 
workstation into the operational database 
without going through the editors. 

A transition to modem, window-oriented 
workstations is taking place at ESOC. The use 
of the currently existing application software 
via the new workstations has already proven 
to sensibly improve the system effectiveness. 
A combination of task-dedicated displays and 
windowed displays is considered to be the 
optimum solution. 

2.3 Telemetry Processing 

The telemetry processing system makes full 
use of a new system software designed to 
handle packetised telemetry. Different tasks 
had to be designed to cope with the 


NASCOM interface for the mission phases 
when telemetry is routed via the Space 
Shuttle through the NASA communications 
network, and the ground station interface for 
the other phases of the mission. 

Standard telemetry processing features are 
provided, like limit checking, validity and 
derived parameters calculation for the 
housekeeping telemetry packets. Other types 
of packets are handled according to the type 
in different ways. 

The problems experienced with the telemetry 
processing system in this first part of the 
mission are all related to the way the system 
reacts to corrupted data received from the 
spacecraft. The large number of independent 
processors on-board EURECA increases the 
likelihood of unexpected behaviours which 
result in corruption of the format or contents 
of the TM packets produced. Very strange 
anomalous behaviours have been observed 
in some of the payload processors, like 
position shifts of packet time field or overflow 
m the packet counter, which caused serious 
problems to the ground software, ranging 
from continuous alarm generation to crashes 
of the telemetry processing tasks. In most of 
the cases ad-hoc software patches have 
become necessary on-ground to cope with the 
new or sporadic anomalous situation. 

The design of a telemetry processing system 
has to be based on some assumptions on the 
structure of the data to be processed, and is 
therefore particularly vulnerable when the 
perverse behaviour of an on-board processor 
corrupts the data in a specific and unexpected 
way. For the same reason, however, the 
system should be flexible enough to allow a 
rapid configuration of the telemetry 
processing software in order to adapt it to the 
new situation in case of an on-board failure. 
The system should for example allow the user 
to disable specific checks on selected packets, 
to modify the time calibration and filing rules 
for specific packets, without the need of 
software modifications. 

2.4 Telecommands Handling 

Three parallel command queues are provided 
for EURECA commanding during a ground 
station pass: the manual commanding queue, 
which allows real-time commanding with 
direct control on single telecommands or 
timed sequences; the pass schedule queue, 
which can be started in the background and 
executes a series of pre-configured commands 
at specified times relative to the start of the 
queue; the maintenance queue, which allows 
uplink of all the previously prepared time- 
tagged commands to be stored on-board for 
later execution. This arrangement allows the 
spacecraft controller to concentrate on the 
manual commands, leaving the control of the 
background automatic queues to the system; 
he is in control of the start and stop of the 
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command activity via the background 
queues. 

Very useful has proven to be the capability 
given to the user to create and store manual 
stacks of commands, which, together with the 
command files editors for pass schedules and 
master schedules provide the required 
flexibility to operate EURECA in the routine 
off-line way, but also to efficiently react in a 
short time to unexpected real-time 
commanding needs. 

When problems in the command link are 
experienced, however, the normally very 
smooth commanding becomes extremely 
difficult to handle. In particular a better 
visibility of the commanding status for the 
different queues would be needed, including 
a direct presentation of spacecraft and ground 
station messages to establish the command 
status. Handling of uplink failures could also 
be improved by automating analysis tasks 
which are currently carried out manually 
whenever failures or interruptions occur 
during the uplink of automatic queues. 

2.5 Automatic Command Verifier 

One of the most useful and widely used 
software tasks in the EURECA control system 
is the automatic command verifier. The 
complexity of telecommand routing on-board 
EURECA and the variety of responses the 
spacecraft can generate which can be used to 
derive the success in telecommand reception 
and execution is handled by a single task. 
Based on user-defined rules contained in the 
definition of each telecommand in the 
operational database the command verifier 
task accesses all telemetry streams and 
summarises the telecommand verification 
result as one of 23 different states, ranging 
from complete success to complete failure; the 
resulting status is recorded in a telecommand 
history File. 

The telecommand history of the previous 24 
hours is analysed daily by an engineer, who 
concentrates his investigation only on those 
few commands which were not completely 
successful. Manually scanning through one 
day of telecommands - typically for EURECA 
routine operations this means about 800 
telecommands -takes only a few minutes if all 
telecommands are successful. On the 
contrary, the investigation of the reasons for 
the failure of only a few telecommands can 
take a significant amount of time. 

Possible improvements to help speeding up 
the trouble-shooting activities related to a 
failed telecommand could be in the area of 
automatic selection of telemetry information 
which is relevant to a selected telecommand; 
also an extension of the verification task to 
allow it to follow in telemetry the entire 
process initiated by a telecommand, and not 
only the successful start of the process, is 


under investigation. This is particularly 
feasible on a spacecraft like EURECA, where 
the high level of on-board automation results 
in long duration automatic processes, lasting 
even several days without intervention from 
ground; the process controllers produce 
periodic or event-driven messages in 
telemetry which give an indication of the 
progress of the activity. 

2.6 Event Messages Handling 

All payload instruments and most of the 
spacecraft subsystems on EURECA generate 
special telemetry packets, called event 
packets, which report asynchronously the 
success of a telecommand, the start, end or 
progress of an automatic process, hardware 
failures or any other unexpected event 
detected on-board. These packets are used in 
the telecommand verification process, but can 
also be displayed on a scrolling display 
which shows for each packet a fixed, user- 
defined text message for each packet. Many 
of these packets also contain housekeeping- 
like parameters: a typical example is a 
snapshot of the entire housekeeping 
telemetry of a payload instrument, generated 
by the instrument processor only at the time 
of a relevant event. This approach, adopted 
by several EURECA instruments, makes the 
best use of the packet telemetry concept, 
generating telemetry information only when 
it is necessary, thus avoiding high frequency 
housekeeping telemetry sampling and 
saving space in the downlink. Parameters 
contained in the event messages can be 
displayed as part of the text message attached 
to the packet and calibration or text 
interpretation can be applied to them in the 
same way as for normal housekeeping 
parameters. 

However event packets parameters are still 
treated separately from the standard 
housekeeping parameters, and therefore not 
integrated in the rest of the telemetry 
processing, like limit checking, validity and 
derived parameters calculation. As there is in 
principle no difference from the on-board 
processor's point of view between 
housekeeping parameters transmitted in an 
event telemetry packet or in a standard 
housekeeping packet, this limitation of the 
EURECA telemetry processing system is 
arbitraiy and causes some difficulties, in 
particular for those payload instruments 
which base their telemetry generation on the 
above described event-driven concept. 

For future autonomous spacecraft event- 
driven reporting will most likely become 
more and more common; a full integration of 
event packet parameters in the telemetry 
processing chain will therefore be mandatory. 

With its limitations the event messages 
display task remains nevertheless one of the 
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most extensively used tools for monitoring of 
the on-going EURECA activities. 

2.7 Flight Dynamics Interface 

The role of flight dynamics software in 
routine mission control of EURECA is very 
important: the low altitude orbit requires 
daily updating of orbit determination and 
predictions; on-board attitude control and 
ground mission planning software also 
require frequent updates of orbit information, 
to keep attitude and planning accuracy 
within the specified requirements. In the first 
weeks of the mission a dedicated flight 
dynamics team was in charge of generating 
the necessary orbit and attitude related 
products using software tools running on a 
dedicated computer. With the progress of the 
mission and the start of the routine operations 
phase the flight dynamics team, which 
mcludes an independent quality control 
group in charge of verification of the 
generated products, has been gradually 
reduced with the target of leaving the routine 
flight dynamics tasks to a set of automatic 
routines which are started daily by a 
scheduler task. These routines perform all 
required tasks from collection of tracking data 
received from the ground stations and orbit 
determination to orbit prediction and related 
products generation, including orbit model 
telecommands to be transferred to the front- 
end computer for uplink to the spacecraft. 

A weak point in this scheme is that 
telecommands are automatically generated 
which cannot be easily checked by the flight 
controllers in charge of uplinking them to the 
spacecraft. Any problem in the automatic 

f eneration software, which can also be caused 
y corrupted input data, is not detected any 
more by the quality control check carried out 
in the first part of the mission. The only 
protection the current system provides is 
limit-checking on telecommand parameters. 
This is however only effective on a limited 
number of parameters and by no means 
represents a complete check. 

Some simple independent software checking 
is being implemented to trap any major 
problem with the automatically generated 
telecommands. A more consistent software, 
possibly based on the same routines which 
were developed and used by the quality 
control team during the early phases of the 
mission, should be implemented for future 
missions and integrated in a more 
comprehensive telecommand generation 
software. 

3. SCIENCE OPERATIONS 

3.1 Mission Planning 

One area where the existing workstation 
interface had to be abandoned years ago is 
the mission planning task. This tool runs on 


an independent VAX workstation where the 
graphical and windowing capabilities are 
used in producing an effective user-interface. 

On the other hand the mission planning is 
probably the area of the mission control 
software which is experiencing the most 
significant problems. The tool accepts 
scheduling inputs based on orbital constraints 
and, using a pre-defined database, it 
produces a resource consumption profile for 
all spacecraft resources available to the 
payload (eg. power, data storage, cooling 
capacity) by adding up the contributions from 
the single scheduled operations. If the total 
resource consumption goes above a pre- 
defined threshold the mission planning tool 
warns the user that a 'dash' is detected, 
allowing him to modify the payload 
operations schedule to solve the problem. 

Experience has shown, however, that the 
type of operational constraints to be applied 
to payload operations scheduling are more 
complicated than simple relations to orbital 
events. Payload operations are often 
constrained by relations between activities to 
be executed on the same or on different 
payload instruments, ground activities, 
specific requirements by the investigators. 
This type of constraints is not handled by the 
mission planning software, and a 
combination of manual scheduling and user- 
developed software had to be adopted to 
simplify the actual planning tasks. An 
additional tool would be required to allow the 
planner to specify and modify rules to be 
used by the mission planning task to 
schedule the required payload operations. 
This tool should be flexible enough to allow 
specification of rules which are normally 
thought of or required by the investigators or 
by new developments in the spacecraft 
situation only later in the mission plan 
preparation and often even during the actual 
mission. 

Resource consumption checking and clash 
detection handling turned out to be less 
critical than expected in the actual planning 
exercise: planners very soon acquire enough 
experience on possible payload configurations 
which allows them to manually produce 
feasible payload operations timelines. A lot of 
development effort was therefore put into a 
less important part of the software task. 

Another problem experienced with the 
available tool is the little visibility the 
planner has on the already scheduled 
operations. This is in particular important 
when changes have to be implemented in 
already scheduled operations due to resource 
availability problems, new failures or new 
requests from the investigators. An analysis 
tool which allows to identify at any point of 
the scheduled timeline what payload 
operation is contributing to the overall 
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payload configuration would be a significant 
improvement required for this task. 

3.2 Data Disposition System 

The science data generated by the payload 
are distributed to the users via electronic 
means: all consolidated spacecraft data are 
accessible from the users via a separate 
computer, which is linked to the operational 
machine and to the external world via 
different communications protocols for 
security reasons. A catalogue of available 
data can be requested via electronic mail by 
the user, who can then specify the 
appropriate request for data from his own 
instrument. Available to the user are also all 
spacecraft housekeeping data and other 
ancillary information files like future orbit 
events, attitude history or telecommand 
history. 

The user can also specify, via the same 
electronic interface, requests for special 
operations to be conducted on his instrument, 
or changes to the pre-mission defined 
operations plan. This type of request, called 
TC Request, forms the input, together with 
the baseline payload operations plan, to the 
daily mission planning exercise. 

Unfortunately the loop with the user is not 
closed electronically: TC requests cannot be 
input directly in the telecommand scheduling 
process but the related telecommands have to 
be manually generated by a mission 
planning engineer. A more automatic 
handling of TC requests was not possible due 
to the large number of payload instruments 
and different types of operation requests, 
together with the limited time and budget 
available for the development of this system. 

A first necessary improvement of the 
interface with external users would be to 
allow the mission planner to include 
electronically the approved TC requests in 
the telecommand generation process. 
Automatic checking and approval of TC 
requests, allowing each user to remotely 
control his own instrument independently of 
the other spacecraft operations is the target, 
still far away from the EURECA approach, 
but at least visible in the distance. 

4. GROUND STATIONS - CONTROL 
CENTRE INTERFACE 

4.1 Telemetry Interface 

Real time and on-board recorded telemetry is 
received and stored at the ground station by 
a telemetry frame pre-processor; During a 
telemetry dump the data rate reaches 256 
Kbps and due to the lower capacity of the 
station to control centre link only a subset of 
the received data can be transferred in real- 
time. The control centre can pre-program the 
station unit to transmit any selection of 


telemetry packets or all real-time or recorded 
telemetry frames as received from the 
spacecraft. 

During the pass only real-time telemetry is 
normally transferred directly to the EDCS, 
whilst the telemetry which is dumped from 
the on-board memory during the pass is 
transferred in the non-coverage period 
between two passes. 

Whilst the nominal data transfer is 
adequately handled by EDCS, the problems 
start in case of interruptions during the data 
dump from the spacecraft or during the data 
transfer from the station. 

If the problem was on the ground link the 
system allows the user to initiate a new 
transfer; unfortunately in this case a re- 
transfer of the entire selected data set is 
performed, and not simply of the data lost on 
the link. Due to the long duration of the 
transfer of all data dumped during the pass 
this becomes a very inefficient ana time- 
consuming operation. 

If the spacecraft-station link is interrupted 
during a telemetry dump the problem is 
more serious and difficult to detect and to 
recover. The system allows in fact detection 
and later filling of gaps created in the 
telemetry history files by any link 
interruption; however the tools available for 
this taslc are very complicated to use and 
require long manual investigations and 
calculations to determine where and when 
the problem occurred and what data have to 
be re-transferred. In many cases this time is 
of the same order of the wraparound time of 
the on-board memory, making the data 
recovery physically impossible. 

A more efficient and user-friendly tool would 
be required to allow immediate detection of 
the gap, identification of whether the data 
were lost on the space-to-ground link or 
between the station and the control centre, 
and indicate what the recovery action should 
be. The necessary information is available on 
ground to completely automate the task, 
leaving to the operator only the decision 
whether to initiate the recovery process or 
not. 

4.2 Telecommand Interface 

Experience during the mission with the 
telecommand interface between EDCS and 
the ground station has been very positive, 
with hardly any problem occurred in more 
than three months and more than 80000 
telecommands uplinked to the spacecraft. 

Problems occurred in the development phase, 
due to the late decision to close tne 
telecommand block protocol loop with the 
spacecraft at the control centre, and not, as 
initially foreseen, at the ground station. This 
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increased dramatically the complication of the 
command uplinks r software, which has to 
cope for every telecommand with a number 
of messages coming from different units at 
the station in addition to the telemetry 
messages from the spacecraft. 

Testing this software in a realistic 
environment became absolutely necessary 
due to the importance of the timing aspects of 
the problem and this forced extension of 
precious testing time with the spacecraft flight 
model connected to a ground station interface. 

For the NASA interface a complete realistic 
test was not possible, leaving the fine tuning 
of several configuration parameters to the 
actual flight experience. 

Fortunately no correction to the uplinker 
software became necessary during the 
mission. It is however advisable, in order to 
simplify significantly the command interface 
software at the control centre, to close as much 
as possible of the space to ground loop at the 
ground station. 

4.3 Tracking Interface 

The interface with the ground station which 
deals with tracking data collection from and 
antenna pointing information transmission to 
the station was given a low priority in the 
software development phase, resulting in a 
relatively simple implementation. 

EURECA tracking data are collected at the 
station by a unit called MPTS, which is 
remotely programmed for operation and data 
transfer from the control centre. The only 
problems experienced are also in this case in 
the area of the user interface, which gives 
little visibility to the spacecraft controller of 
the status of the unit and in particular of the 
contents and status of the programmed 
queues. 

Antenna pointing information is generated 
by the flight dynamics automatic software, 
and transferred to the ground station by the 
network operators on a daily basis. In this 
case too, the operator in charge of the transfer 
has no visibility of the contents of the files he 
is transferring, and only when the data reach 
the station any problem that may have 
occurred becomes available. A recurrent 
problem in the first part of the mission was in 
fact that antenna pointing data were not 
reaching the station in time, or the station 
would request new data which were not yet 
available. 

This type of visibility problems are usually 
worked around by experience and 
procedures improvement in the first months 
of the mission. However, a more elegant 
interface which links directly the flight 
dynamics generation software to the ground 
station computer and performs the data 


generation or transfer automatically or on 
request would be a significant improvement 
in this area. 

5. CONCLUSIONS 

The EURECA ground segment has to date 
successfully supported this challenging 
mission for almost half of its nominal lifetime. 

Spacecraft routine operations still keep a team 
of eight spacecraft controllers and eight 
engineers extremely busy; the ground 
segment is however helping to carry out the 
daily tasks in time, and this is also shown by 
the fact that we could afford the time to write 
and present this paper. 

The experience gained with the EURECA 
mission control should be used to improve for 
future missions the ground segment 
reliability and to reduce the involvement of 
man in all those tasks which can in principle 
be automated. 
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